polemos royale
Polemos Royale is a remake of the original Polemos, but with a battle royale twist. It allows for more players, more events and more customization and a map through which the players can move and roll dice to determine the outcome of the events.
Description
Polemos Royale is a remake of my previous project, Polemos, like the first implementation, Polemos Royale is a text based battle simulator inspired by BrantSteele's Hunger Games Simulator. The idea is the same as before, have a cast of user-selected characters and run a simulation to see who comes out on top, while reading the twists and turns of the story that unfolds.
Polemos Royale is a remake of the original project, distilling the idea to it's core components and building upon them. This time features like authentication, user management, and more were stripped away, focusing on the core functionality of the project. Once I felt like the implementation of the core features was solid and reflected what I wanted to achieve, I started adding new features, the main difference with this implementation and all previous ones is the addition of what we call locations these locations come in 2 types, "tiles" and "hazards". The idea behind this addition is to attach events to locations and have the simulation work with that instead of having a never ending array of events that can happen at any time. This we can mold the story to our liking, having each game be unique. Much like how spotify realised that people don't want true randomness in their playlists we realised that we didn't want true randomness in our simulations, it often lead to events repeating themselves or anticlimatic endings. Locations are our way of controlling the flow of the simulation and removing the bad parts of 100% randomness, while leaving the uncertainty that makes the simulation fun.
The game now runs on a hexagonal grid of tiles, each tile having any given number of hazards on them, leading to characters on that tile being able to "roll" events related to either of those sources. As the game progresses we can see the characters move to new locations, giving a sense of anticipation of what they might face, all these movements eventually leading to a final showdown on the center of the stage where we can remove anticlimatic endings and have a final battle between the last remaining characters.
Polemos Royale is a remake of the original project, distilling the idea to it's core components and building upon them. This time features like authentication, user management, and more were stripped away, focusing on the core functionality of the project. Once I felt like the implementation of the core features was solid and reflected what I wanted to achieve, I started adding new features, the main difference with this implementation and all previous ones is the addition of what we call locations these locations come in 2 types, "tiles" and "hazards". The idea behind this addition is to attach events to locations and have the simulation work with that instead of having a never ending array of events that can happen at any time. This we can mold the story to our liking, having each game be unique. Much like how spotify realised that people don't want true randomness in their playlists we realised that we didn't want true randomness in our simulations, it often lead to events repeating themselves or anticlimatic endings. Locations are our way of controlling the flow of the simulation and removing the bad parts of 100% randomness, while leaving the uncertainty that makes the simulation fun.
The game now runs on a hexagonal grid of tiles, each tile having any given number of hazards on them, leading to characters on that tile being able to "roll" events related to either of those sources. As the game progresses we can see the characters move to new locations, giving a sense of anticipation of what they might face, all these movements eventually leading to a final showdown on the center of the stage where we can remove anticlimatic endings and have a final battle between the last remaining characters.
Technologies
For this project, I continued using Next.js as the main framework, which has proven to be an excellent choice for rapid development and iteration. Tailwind CSS once again employed for styling, opting for Shadcn as the component library to speed up the development process.
On the backend, I utilized tRPC to handle the communication between the frontend and backend, ensuring type-safe API calls.
For deployment, I decided not to deploy it, the deployment could easily be done on Vercel without mayor issue but since I will be using it for personal use I decided to keep it local.
On the backend, I utilized tRPC to handle the communication between the frontend and backend, ensuring type-safe API calls.
For deployment, I decided not to deploy it, the deployment could easily be done on Vercel without mayor issue but since I will be using it for personal use I decided to keep it local.
Things Learned
This project was a great way to learn more about the importance value of iteration. As I stripped the project to its core features, I realized the true essence of the project and what I wanted to achieve. This allowed me to focus on the core features and build upon them, and find why the project was interesting to me in the first place.
The shift from doing a proyect for the public to doing a project for myself was also a great learning experience, I was able to focus on what I wanted to do and how I wanted to do it, removing features that would be required in a public project but that I didn't need for my personal use.
This proyect made me realize some benefits of doing the same proyects over and over, I already knew the problems I would face and how to solve them, I could focus solely on the new features and how to implement them, instead of having to figure out how to do the core functionality of the project. I knew what worked and what didn't and could design and work based on that, having feedback of previous iterations to guide me.
The shift from doing a proyect for the public to doing a project for myself was also a great learning experience, I was able to focus on what I wanted to do and how I wanted to do it, removing features that would be required in a public project but that I didn't need for my personal use.
This proyect made me realize some benefits of doing the same proyects over and over, I already knew the problems I would face and how to solve them, I could focus solely on the new features and how to implement them, instead of having to figure out how to do the core functionality of the project. I knew what worked and what didn't and could design and work based on that, having feedback of previous iterations to guide me.
Things I Would Do Differently
Not much honestly, I'm pretty happy with how it turned out, the main thing would be to give the aesthetic a bit more of a unique feel, it feels a bit generic because of the use of a component library, but that's a tradeoff with having a faster development process and standardized components that look good. I remember reading about how using component libraries allow for a higher "design floor" where everything you do will look decent but molding it into something with soul is harder.
Gallery
